The IEEE 802.21 draft standard is being developed to provide a framework for enabling the exchange of support messages (i.e. 802.21 information, events, and commands) between network and mobile nodes, to achieve seamless media independent handover (MIH). The IEEE 802.21 group develops mechanisms and procedures that aid in the execution and management of inter-system handovers.
A media independent handover function (MIHF) is a framework defined by 802.21 that facilitates handover across heterogeneous access networks and to help MIH users (e.g., mobile users, mobile nodes) experience a better performance during seamless handover. The MIH user makes handover decisions based on input from the MIHF. The MIHF is a function implementation of MIH services and is treated as a logical entity implemented in both MIH users and in the network.
FIG. 1 is a block diagram of layer link connections between MIH-enabled nodes and networks using MIH functional entities. A mobile node 101 is shown comprising a MIHF 102, a lower layer interface 103 for 3GPP/3GPP2 networks, a lower layer interface entity 104 for IEEE 802 networks, and one or more MIH Users 105.
The MIHF 102 is coupled to the heterogeneous access networks (3GPP/802) using MIH local interface 115 and MIH message transports 112, 113. The MIH user(s) 105 communicates to the MIHF 102 in mobile node 101 via MIH local interface 111. The MIH User is defined in 802.21 as an entity that uses the services provided by the MIHF; the MIH user is typically a policy driven functional entity and invokes the MIHF to manipulate the lower layers for media dependent or independent services. Higher layer transport connections 120, which are at L3 layer, allow the MIHF 102 to communicate with remote MIHFs 132 and 142 of the 802 network 131 and the 3GPP network 141, respectively. When connected to the 802 network 131, the mobile node 101 may alternatively use L2 layer transport interfaces 112 and 113 for management and data transfer between the functional entity 802 interfaces 104 and 134.
The MIHF provides services to MIH users through a single media-independent interface, the MIH service access point (MIH-SAP), which is a point in a protocol stack where services of a lower layer are made available to a next higher layer. The MIHF obtains services from lower layers (i.e., link layers) through a variety of media-dependent interfaces (media specific SAPs). One type of service handled by the MIHF is a Command Service which is broadly divided into two categories: Link Commands and MIH Commands. FIG. 2 shows a block diagram of a protocol stack of a mobile node 201 comprising an MIHF 202, which receives MIH commands 212 from the local MIH User or Users 203, which operates on upper layer L3 and above. Link Commands 211 are sent by the MIHF 202 and directed to lower layers 204, which are on L2 and below, and include for example MAC, radio resource management, and physical layer (PHY). Although Link Commands 211 originate from the MIHF 202, these commands are executed on behalf of the MIH Users. The MIH Commands 212 are generated by the MIH Users and sent to the MIHF 202 (e.g., from upper layer mobility protocol to MIHF, or from policy engine to MIHF).
The Link commands 211 and MIH commands 212 are executed using service primitives, which are defined in 802.21 as a conceptual abstraction to describe the information transfer that occurs between an upper layer user and the present layer in the provisioning of a service. Each service primitive conveys one or more information parameters. As shown in FIG. 2, the MIHF 202 receives MIH primitives from the MIH User 203, such as an MIH Command request 222, and determines whether or not one or more link layer primitives, such as Link Command request 221, should be triggered in order to satisfy the request from the MIH User 203. Likewise, the MIHF 202 may generate MIH primitives toward the MIH User 203, shown as an MIH Command confirm 232, upon receipt of one or more link layer primitives coming from lower link layers 204, shown as Link Command confirm 231. Such confirmation primitives report results of the Link Command Execution 241.
The 802.21 link layer primitives may be mapped directly or indirectly into existing primitives supported by other link layer technologies. In this regard, the link layer primitives described by 802.21 serve as a “blueprint” of what is expected from a specific link layer technology and therefore a mapping can be established between these “blueprint” primitives and one or more existing primitives within a relevant link layer technology, such as 802.11, 802.16 or even 3GPP/3GPP2.
With regard to command services, and in particular commands that allow the manipulation of link layer resources, a method of performing a mapping of handover commands coming from the MIH user and link commands triggered by the MIHF is needed. Early drafts of the 802.21 standard provide for a command to order actions on the existing link layer connection. These actions are only applicable to one link (i.e., the current link) and the command only flows from the MIH User to the MIHF. Although there is some indication that some action can be taken by the MIHF on receipt of this command, there are no standardized primitives that support such procedures. Thus, it currently undefined how these procedures should be carried out.
Prior drafts of the 802.21 standard support a number of MIH commands from the MIH User to the MHIF that might cause a service flow to switch from one link layer connection to another. For example, there are MIH messages to command other link-specific tasks, such as powering up, powering down, and changing transmission and/or reception mode. Although there are several MIH primitives that can trigger link layer actions, there are no corresponding 802.21 link layer counterpart or “blue print” primitives, as is the case with other commands, events and information services.
Prior drafts of the 802.21 standard (e.g., version D01.09) make references to Link commands that should be used by the MIHF when it receives MIH commands affecting link layer connection. However, these link layer commands remain undefined. Additionally, these existing MIH commands only allow actions to be taken on one link at a time, and it is not clear what action should be taken on the new link layer connection that needs to be established for the handover to be executed.
In 802.21 standard drafts subsequent to version D01.09, a primitive called Link Action has no way of indicating to the link layer to perform actions such as scanning on a link or enabling/disabling transmission/reception. Additionally, there exists an MIH primitive, called MIH Switch, to specifically command link actions to be performed on the old link during a handover scenario from an “old link” to a “new link”. However, this MIH Switch primitive does not allow specification of actions to be performed on the new link. The primitive is also limited to only interacting with two links, which is problematic for cases when interaction with more than two links is required.